masterofmagicfandomcom-20200216-history
Forum:"Fluid" width
Tables and Charts The new "Fluid width" process has been implemented. From what I can tell, based on a test with the Normal Unit's page, is that the options from the drop-down-menu allow us to see how the page will look based on the View settings of a persons browser or device. The scroll-bars at the bottom of a number of our tables/charts ONLY appear if our View settings are set to a normal setting (current width). In other words, the page will look a bit different to everyone based on the settings of the device they are using at the time. The "Fluid" width currently only allows us to see how a page looks to someone, using 4 different view settings/devices and only when previewing before publishing (in edit mode preview). The short, most of the charts look like we want them to if the minimum width or maximum width is chosen - not if the "current width" is chosen. This means changes to pages with charts is NOT necessary to get rid of the scroll bar and only limit our tables if we try to use shorter-width versions. I haven't really done much with it so, if anyone discovers some actual benefits or improvements...please note them here. MysticX2 (talk) 11:50, December 8, 2013 (UTC) :One thing about table cells is that no-wrap text now gets re-scaled if the cell width was pre-defined, though I can't remember what was going on beforehand. I have been sizing table cells in order to make them appear more uniform and legible, but maybe I need to stop that, so the code can attempt to scale the table cells automatically around different widths (The basic idea being to generate a half-decent presentation for everybody, rather than a perfect presentation for a few). :I think one of the relevant points to us about the mobile device presentation is that it discards style and maybe span tags around the content, and with tables I believe it discards either width-percent or width-pixel parameters (can't remember which). This means that virtually all of the pre-existing "gradientable" class-charts on the wiki, as well as certain ones I've made recently that try to cram information into the page width through "style=", will be difficult to read even with the new code. But I think we should be straightforward in saying that this wiki isn't really meant to be accessed on-the-go by mobiles, it's meant for people at home with desktops and laptops with 1024px or 1900px screens and DosBox open and all that nonsense. At least I think so. --Spearman D92-R (talk) 19:55, December 8, 2013 (UTC) ::I agree that the expected use for this wiki is from desktops and laptops, not so much from mobile. As for discontinuing your sizing the cells, that's up to you. I just don't see any reason to redo the tables/charts that are already existing for sizing. MysticX2 (talk) 23:57, December 8, 2013 (UTC) : I intended too make tables, that are slighlty too wide, narrower. This "Fluid" width has no influence on the oversized tables, right? You cannot edit the current width of pages?! You just can influence how the preview is displayed. -- RJAK (talk) 07:46, December 9, 2013 (UTC) ::The preview will show you the way it will look based on a user's settings. It really has no influence on a page that I can find at this time (except as described by Spearman). I changed the settings on my computer and the tables look fine on most of the tables/charts. That's why I say that it doesn't really accomplish anything by sizing existing tables/charts. Now if there are changes to be made to a table/chart anyway, you can re-size then if you like (it is still unnecessary, and probably a lot easier to change your view settings). I also think that wikia will make allowances for larger charts, possibly based on one of my suggestions because it wasn't an issue isolated to this wiki. ::And no, you cannot edit a pages width other than changing your view settings. These lists, Lists, should not be changed for sizing because they are sortable and need to remain that way. MysticX2 (talk) 10:19, December 9, 2013 (UTC) I am anticipating the likelihood that a number of charts will gain an additional column in the near future, and trying to avoid making numerous changes to the same chart. Also, the chart will appear somewhat different to every user and at least the preview allows you to see how it looks other than on your own screen. MysticX2 (talk) 10:29, December 9, 2013 (UTC) ::: I am speaking of tables which weren't changed in the last year. I still don't understand, what you mean with "how it looks other than on your own screen". If I understood it correctly, there are just 2 ways the Wiki is displayed: Mobile devices and desktops. The wiki width is the same for all desktop users?! (independent of your screen size and settings) -- RJAK (talk) 07:08, December 10, 2013 (UTC) Hero Table I've made a table with most hero properties listed. It could be used on Summon Hero page or on the still to create hero page (I know this Wiki will never be completed, but I still have the hope that some 'red' pages will disappear). What is missing: upkeep & hiring cost (though this can be calculated from Fame requirement), weapon slots, types of random picks (perhaps one could illustrate this with different colors). -- RJAK (talk) 23:24, March 6, 2014 (UTC) :Could use for warrior, for wizard, for both.Yramrag (talk) 01:59, March 7, 2014 (UTC) ::Yeah the shield spot just depends on the weapon slot: sword + staff -> shield staff only -> amulet Problem is: there is not enough space in the table. LOL your comment transformed * to * . This is a serious problem and I don't know how to get rid of it. Let's fix it manually. Unit Tables discussion Here the unit tables narrowed, so that they fit in 700 pixel. Since I wasn't involved in making the race pages, I'll put them here, and you can decide to do with them. I corrected that Trirems need 1 food and War Ships transport 3 units. I deleted the ground movement from the Lizardmen units; otherwise the table wouldn't have fit in. I followed the Dwarves example. I didn't make any further changes except changing buildings to 24px and using negative margin from time to time. Here some suggstions: I wouldn't use the templates ToHit and Movement|Ships in the Abilities column because of the white font. I think there should be more space between Hits and Abilities columns (hmm extra column and colspan=2?). And I would replace the icon with . -- RJAK (talk) 23:24, January 22, 2014 (UTC) : I think I agree with MX2's advice that we should have the movement types pages up before, well, moving on these tables. My Dwarf edit was a sort of proposal and that's what I got out of it. I have the feeling that when these pages are written, an optimal move template for the site might become more apparent (particularly to the writer of the pages). If these tables are something you wanted to handle right now, then by all means do it, though if you set up the movement pages, you'll get that much more control... --Spearman D92-R (talk) 02:11, January 23, 2014 (UTC) :: I don't see a big connection between resizing tables and changing movement. I don't think it'll effect many tables anyway. There're Lizardmen, High Elves, Dwarves and Rangers, that's it. -- RJAK (talk) 18:49, January 23, 2014 (UTC) : What I am trying to establish is that there are the icons that are used on the unit information windows that represent the main movement and default terrain of a unit. Then there are the movement type icons that represent the movement costs associated with moving into an adjacent terrain. Using the sailing icon in the same column with other icons that are used on the unit information window is using them incorrectly. If the sailing icons need to be used in these charts there should be another column. The first column should be the main movement using the THREE icons representing ground, water, and air. The second column could use icons that represent the movement types, but the boot icon in that should be the one that represents Grasslands movement type which is the most common Ground Movement. : Regardless of how it is said, I cannot find a way to always match the use on the wiki and the use in the game and the use in the code. The only thing I can come up with at this point is to say that the rule is basically outlined above and any other use is only going to lead to confusion. This should work as long as the usage and terminology remains consistent. : As for replacing the icon with , the problem I have with that is how it is used and how it appears in the game and if adopting the "rule" then is the more appropriate. MysticX2 (talk) 15:58, January 23, 2014 (UTC) : As for resizing the charts there really isn't a need to do that because it pushes things closer together just because your settings don't allow you to see the full chart. You assume that most people's settings are the same or similar to yours and that it benefits more people to downsize them. This may be true, but I also think that there are changes coming to wikia that will make changing the charts unnecessary and then there are just a bunch of scrunched-down-charts that would have looked fine if left alone to begin with. MysticX2 (talk) 16:12, January 23, 2014 (UTC) :: I assume it looks the same for everybody currently, and I don't kow if it will change eventully. For me it looks like this, which is suboptimal: -- RJAK (talk) 18:54, January 23, 2014 (UTC) :::Lizardmen look like that to me as well. Arguably what we should do is use width=x% instead of a constant width value, letting it automatically resize itself if the panel changes size. Yramrag (talk) 19:23, January 23, 2014 (UTC) Unit Tables Narrower unit tables: